REMARKS 

Reconsideration of the present application, as amended, is respectfully 
requested. Claims 2, 3, 13, 41 , and 42 have been amended. No claims have been 
cancelled or added. 

Applicants wish to thank the Examiner for his willingness to conduct an interview. 
Applicants attempted to contact the Examiner twice during the this period, and were 
unable to do so. Applicants apologize, and request that the Examiner contact the 
undersigned at 408-720-8300 x269, or 408-368-6048 at any time to discuss any claim 
amendments that would be useful in putting the present invention into proper format for 
allowance. 

Examiner rejected claims 1-6, 9-13, 16-48, and 51-52 under 35 U.S.C. §1 02(b) 
as being anticipated by U.S. Patent No. 5,915,1 12 to Boutcher. 

Claim 1 recites in part "identifying at least one particular host device that is 

connected to the first device, including determining communication information allowing 

communication between the first device and the particular host device, and determining 

command information allowing the first device to invoke execution of the application or 

driver of interest at the particular host device." The Examiner suggests that column 3, 

lines 35052 of Boutcher teach this element. Applicants respectfully disagree. The 

systems of Boutcher use an RPC protocol. And as Boutcher notes: 

In general, to develop an RPC application, the desired interface between a 
client and a server is defined using an interface definition language (IDL) 
which specifies the desired remote procedures and the data structures, 
constants, and parameters required for implementation of the procedures. 
For example, FIG. 3 illustrates a typical RPC interface, which generally 
has the form: 
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interface interface name> version (<major> [:<minor>]) {declarations} 
Next the interface file is compiled using an IDL compiler. Typically, 
compilation of the interface file results in four files. On the client system, 
client stub and client header files are generated. ... Similarly two files are 
generated on the server system, including the server stub file and a server 
header file. (Column 6, line 55 to column 7, line 7). 

(Column 6, line 55 to column 7, line 7). 

Therefore, inherent in the RPC protocol described by Boutcher is the creation of 
these client and server stubs prior to the ability to utilize the RPC, and prior to the 
connection of the server to the client for execution of processes . In contrast, claim 1 of 
the present invention recites "determining command information allowing the first device 
to invoke execution of the application or driver of interest at the particular host device" 
when the "particular host device is connected to the first device." In Boutcher's system, 
such an identification is unnecessary, since the preexisting client and server stubs 
provide this information. Therefore, no such identification takes place when the first 
device is coupled to a host device. 

Therefore, claim 1 , and claims 2-13 and 16-40 which depend on it are not 
obvious over or anticipated by Boutcher. 

Claim 41, as amended, recites in part "transmitting at least one command from 
the first device that invokes execution of the driver of interest at the second device, 
whereupon the driver executes at the second device, the driver for controlling the 
interaction between the first device and the second device, and further for controlling 
the operation of the first device ." The purpose of using RPC, as noted by Boutcher is to 
reduce the amount of code necessary, by using the client and server stubs. There is no 
need for the client to send anything beyond the actual application program, because the 
server stub understands how to handle the application data sent. In contrast, claim 41 
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notes that the uploaded application is a driver for controlling the interaction between the 
first device and the second device . The interaction between the devices of Boutcher 
are controlled by the pre-existing server/client stubs. 

Therefore, claim 41 , and claims 42-50 which depend on it, are not obvious over 
or anticipated by the references. 

Claim 51 recites in part " a physical manager identify a host coupled to the client 
device." Applicants respectfully submit that Boutcher does not teach or suggest such a 
physical manager. The communication between a server and a client using RPC is 
scripted. The client knows the host, and does not need to identify it. Therefore, claim 
51 , and claim 52 which depends on it, are not obvious over or anticipated by the 
references. 

Examiner rejected claims 7-8 and 49-50 under 35 U.S.C. §1 03(a) as being 
unpatentable over Boutcher in view of U.S. Patent No. 5,928,325 to Shaughnessy et al. 

Claims 7-8 depend on claim 1, and claims 49-50 depend on claim 41. 
Shaughnessy does not remedy the shortcomings of Boutcher discussed above with 
respect to the parent claims. Therefore, claims 7-8 and 49-50 are not obvious over the 
combination of references. 

Applicant respectfully submits that in view of the amendments and discussion set 
forth herein, the applicable rejections have been overcome. Accordingly, the present 
and amended claims should be found to be in condition for allowance. 

If a telephone interview would expedite the prosecution of this application, the 
Examiner is invited to contact Judith Szepesi at (408) 720-8300. 
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If there are any additional charges/credits, please charge/credit our deposit 
account no. 02-2666. 



Customer No. 08791 
12400 Wilshire Blvd. 
Seventh Floor 
Los Angeles, CA 90025 
(408) 720-8300 
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Respectfully submitted, 
BLAKELYj SOK0LOFF 



Dated: July 26. 2005 



